<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="Author" content="Eclipse Project PMC">
<title>The Eclipse Project DRAFT 3.3 Plan</title>
<link rel="stylesheet" href="../../default_style.css" type="text/css">
</head>
<body>

<h1>The Eclipse Project FINAL 3.3 Plan</h1>

Last revised 17:00 EST Aug 15, 2007
  (<img src="new.gif" alt="(new)" border="0" height="12" width="12">
  marks interesting changes since the previous 
  <a href="eclipse_project_plan_3_3_20070330.html">draft of March 30, 2007</a>)

<p><i>&nbsp;&nbsp;&nbsp; Please send comments about this draft plan to the</i>
  <a href="mailto:eclipse-dev@eclipse.org">eclipse-dev@eclipse.org</a>
  <i>developer mailing list.</i>
</p>
<p>This document lays out the feature and API set for the next feature release 
  of the Eclipse SDK after 3.2, designated release 3.3. 
</p>
<ul>
  <li><a href="#Deliverables">Release deliverables</a></li>
  <li><a href="#Milestones">Release milestones</a></li>
  <li><a href="#TargetOperatingEnvironments">Target operating environments</a></li>
  <li><a href="#Compatibility">Compatibility with previous releases</a></li>
  <li><a href="#ThemesandPriorities">Themes and Priorities</a></li>
  <li><a href="#WorkAreas">Work Areas</a></li>
</ul>

<p>Plans do not materialize out of nowhere, nor are they entirely static. To ensure 
  the planning process is transparent and open to the entire Eclipse community, 
  we (the Eclipse Project PMC) post plans in an embryonic form and revise them 
  throughout the release cycle. 
</p>
<p>The first part of the plan deals with the important matters of release
  deliverables, release milestones, target operating environments, and
  release-to-release compatibility. These are all things that need to be clear for
  any release, even if no features were to change.
</p>
<p>The remainder of the plan consists of plan items for all of the sub-projects under 
  the top level Eclipse Project. Each plan item covers a feature or API 
  that is to be added to the Eclipse Project deliverables, or some aspect of the Eclipse Project 
  that is to be improved. Each plan item has its own entry in the Eclipse bugzilla 
  database, with a title and a concise summary (usually a single paragraph) that 
  explains the work item at a suitably high enough level so that everyone can 
  readily understand what the work item is without having to understand the nitty-gritty 
  detail. 
</p>
<p>Not all plan items represent the same amount of work; some may be quite
  large, others, quite small. Some plan items may involve work that is localized
  to a single component; others may involve coordinated changes to
  several components; other may pervade the entire SDK. Although some plan
  items are for work that is more pressing than others, the plan items appear in
  no particular order.
</p>
<p>With the previous release as the starting point, this is the plan for how we
  will enhance and improve it. Fixing bugs, improving test coverage,
  documentation, examples, performance tuning, usability, etc. are considered routine
  ongoing maintenance activities and are not included in this plan unless they
  would also involve a significant change to the API or feature set, or involve a
  significant amount of work. The intent of the plan is to account for all interesting feature work.
</p>
<p>The current status of each plan item is noted:
</p>
<ul>
  <li><b>Committed</b> plan item - A committed plan item is one that we have
    decided to address for the release.</li>
  <li><b>Proposed</b> plan item - A proposed plan item is one that we are
    considering addressing for the release. Although we are actively
    investigating it, we are not yet in a position to commit to it, or to say
    that we won't be able to address it. After due consideration, a proposal
    will either be committed or deferred.</li>
  <li><b>Deferred</b> plan item - A reasonable proposal that will not make it in
    to this release for some reason is marked as deferred with a brief note as
    to why it was deferred. Deferred plan items may resurface as committed plan
    items at a later point.</li>
</ul>

<h2><a name="Deliverables"></a>Release deliverables</h2>

<p>The release deliverables have the same form as previous releases, namely:
</p>
<ul>
  <li>Source code release for all Eclipse Project deliverables, available as versions 
    tagged "R3_3" in the Eclipse Project <a href="http://dev.eclipse.org/viewcvs/">CVS 
    repository</a>.</li>
  <li>Eclipse SDK (runtime binary and SDK for Equinox, Platform, JDT, and PDE) (downloadable).</li>
  <li>Eclipse Platform (runtime binary and SDK for the Equinox and Platform only) (downloadable).</li>
  <li>Eclipse RCP (runtime binary and SDK for the Rich Client Platform) (downloadable).</li>
  <li>Eclipse JDT (runtime binary and SDK for the Java Development Tools) (downloadable).</li>
  <li>Eclipse PDE (runtime binary and SDK for the Plug-in Development Environment) (downloadable).</li>
  <li>Eclipse SDK Examples (downloadable).</li>
  <li>SWT distribution (downloadable).</li>
  <li>Equinox OSGi R4 framework and assorted service implementations (downloadable).</li>
</ul>

<h2><a name="Milestones"></a>Release milestones</h2>

<p>Release milestones, occurring at roughly 6 week intervals, exist to facilitate 
  coarse-grained planning and staging. The milestones are:
</p>
<ul>
  <li> Thursday Aug. 10, 2006 - Milestone 1 (3.3 M1) - stable build</li>
  <li> Friday Sep. 22, 2006 - Milestone 2 (3.3 M2) - stable build</li>
  <li> Friday Nov. 3, 2006 - Milestone 3 (3.3 M3) - stable build</li>
  <li> Friday Dec. 15, 2006 - Milestone 4 (3.3 M4) - stable build</li>
  <li> Friday Feb. 9, 2007 - Milestone 5 (3.3 M5) - stable build</li>
  <li> Friday Mar. 23, 2007 - Milestone 6 (3.3 M6) - stable build - API complete - API Freeze</li>
  <li> Friday May 4, 2007 - Milestone 7 (3.3 M7) - stable build - feature complete - development 
    freeze - lock down and testing begins</li>
</ul>
<p>Our target is to complete 3.3 in late June 2007. All release deliverables will be available
  for download as soon as the release has been tested and validated in the target operating
  configurations listed below.
</p>

<h2><a name="TargetOperatingEnvironments"></a>Target Operating Environments</h2>

<p>In order to remain current, each Eclipse release targets reasonably current
  operating environments.
</p>
<p>Most of the Eclipse SDK is "pure" Java code and has no direct
  dependence on the underlying operating system. The chief dependence is
  therefore on the Java Platform itself. Portions of the Eclipse SDK
  (including the RCP base, SWT, OSGi and JDT core plug-ins) are targeted
  to specific classes of operating environments, requiring their source
  code to only reference facilities available in particular class
  libraries (e.g. J2ME Foundation 1.0, J2SE 1.3 and 1.4, etc.).
 </p><p> 
  In general, the 3.3 release of the Eclipse Project is developed on a
  mix of Java 1.4 and Java5 VMs. As such, the Eclipse Project SDK as
  a whole is targeted at both 1.4 and Java5 VMs, with full functionality 
  available for 1.4 level development everywhere, and new Java5 specific
  capabilities available when running on a Java5 VM. Similarly, in cases
  where support has been added for Java6 specific features (e.g. JSR-199,
  JSR-269, etc.) Java6 VMs are required.
</p><p>
  <a href="#Appendix1">Appendix 1</a> contains a table that indicates
  the class library level required for each plug-in.
</p>

<p>There are many different implementations of the Java Platform running atop 
  a variety of operating systems. We focus Eclipse SDK testing on a handful 
  of popular combinations of operating system and Java Platform; 
  these are our <em>reference platforms</em>. Eclipse undoubtedly runs fine in 
  many operating environments beyond the reference platforms we test, including
  those using Java6 VMs. However, since we do not systematically test them we
  cannot vouch for them. Problems encountered when running Eclipse on a non-reference
  platform that cannot be recreated on any reference platform will be given lower
  priority than problems with running Eclipse on a reference platform.</p>
  
<p>
The Eclipse SDK 3.3 is tested and validated on the following reference 
platforms (this list is updated over the course of the release cycle):</p>

<center>
<table border="1" cellpadding="2" cellspacing="2" width="80%" summary="Eclipse Reference Platforms">
<tbody>

<tr align="center">
<td><b>Reference Platforms</b></td>
</tr>

<tr><td>
<b>Microsoft Windows Vista, x86-32, Win32</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Microsoft Windows</li>
<li>IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4 (see caveat below)</li>
<li>BEA JRockit 5.0, for Microsoft Windows</li>
</ul>
</td></tr>

<tr><td>
<b>Microsoft Windows XP, x86-32, Win32</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Microsoft Windows</li>
<li>IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4</li>
<li>BEA JRockit 5.0, for Microsoft Windows</li>
<li>Sun Java 2 Standard Edition 1.4.2_14 for Microsoft Windows</li>
<li>IBM 32-bit SDK for Windows, Java 2 Technology Edition 1.4.2 SR7</li>
<li>BEA JRockit 1.4.2, for Microsoft Windows</li>
</ul>
</td></tr>

<tr><td>
<b><img src="new.gif" alt="(new)" border="0" height="12" width="12"> Red Hat Enterprise Linux 5.0, x86-32, GTK</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Linux x86</li>
<li>IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR4</li>
<li>BEA JRockit 5.0, for Linux x86</li>
<li>Sun Java 2 Standard Edition 1.4.2_13 for Linux x86</li>
<li>IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 1.4.2 SR7</li>
<li>BEA JRockit 1.4.2, for Linux x86</li>
</ul>
</td></tr>

<tr><td>
<b>SUSE Linux Enterprise Server 10, x86-32, GTK</b> running (any of):
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Linux x86</li>
<li>IBM 32-bit SDK for Linux on Intel architecture, Java 2 Technology Edition 5.0, SR4</li>
</ul>
</td></tr>

<tr><td>
<b>Red Hat Enterprise Linux 4.0 update 2, x86-64, GTK</b> running:
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Linux x86_64</li>
</ul>
</td></tr>

<tr><td>
<b>Sun Solaris 10, SPARC, GTK</b> running:
<ul>
<li>Sun Java 2 Standard Edition 5.0 Update 11 for Solaris SPARC</li>
</ul>
</td></tr>

<tr><td>
<b>IBM AIX 5.3, Power, Motif 2.1</b> running:
<ul>
<li>IBM 32-bit SDK, Java 2 Technology Edition 5.0, SR4</li>
</ul>
</td></tr>

<tr><td>
<b>Red Hat Enterprise Linux 4.0 update 2, Power, GTK</b> running:
<ul>
<li>IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 7</li>
</ul>
</td></tr>

<tr><td>
<b>SUSE Linux Enterprise Server 10, Power, GTK</b> running:
<ul>
<li>IBM 32-bit SDK for Linux on pSeries architecture, Java 2 Technology Edition 1.4.2 service release 7</li>
</ul>
</td></tr>

<tr><td>
<b>Apple Mac OS X 10.4, Universal, Carbon</b> running:
<ul>
<li>Apple Java 2 Platform Standard Edition (J2SE) 5, service release 4 for Tiger</li>
</ul>
</td></tr>

</tbody>
</table>
</center>

<dl>
<dt><em>Caveat: Using IBM 32-bit SDK for Windows, Java 2 Technology Edition 5.0, SR4 on Vista</em></dt>
<dd>Although we expect this to be fixed in IBM Java5 SR5, there is currently a conflict between
the use of DirectDraw by the <strong>AWT</strong> libraries in IBM Java5 SR4 and
the Windows Vista "Aero" theme. Although the Eclipse SDK itself does not use these libraries
(and thus runs well on Windows Vista using that VM), other plug-ins that make use of the 
conflicting AWT capabilities may cause the advanced features of Aero to be disabled. As a
workaround to avoid this problem, you can add <code>-Dsun.java2d.noddraw=true</code> to the
VM arguments when launching Eclipse, which will prevent the AWT libraries from using DirectDraw. 
</dd>
</dl>

<p>Because Java 1.4.2 and Java5 based platforms are used for most Eclipse
  development, those platforms are listed here. Although there are teams
  doing some Java 6 based development we have not included specific Java6 VMs,
  since they have not yet received the general level of testing we require.
  <i>We expect that Eclipse will work fine on other current Java VMs
  running on window systems supported by SWT, but can not flag these as reference
  platforms without significant community support for testing them.</i></p>
  
<p>Similarly, although untested, the Eclipse SDK should work fine on other OSes that 
  support the same window system. For Win32: NT, 2000, and Server 
  2003; SWT HTML viewer requires Internet Explorer 5 (or higher). For GTK on other 
  Linux systems: version 2.2.1 of the GTK+ widget toolkit and associated libraries 
  (GLib, Pango); SWT HTML viewer requires Mozilla 1.4GTK2. For Motif on 
  Linux systems: Open Motif 2.1 (included); SWT HTML viewer requires Mozilla 1.4GTK2.</p>

<p>SWT is also supported on the QNX Neutrino operating system, x86 processor, 
  Photon window system, and IBM J9 VM version 2.0. Eclipse 3.3 on Windows or Linux 
  can be used to cross-develop QNX applications. (Eclipse 3.3 is unavailable on QNX 
  because there is currently no 1.5 J2SE for QNX.)</p>
  
<h4>Internationalization</h4>

<p>The Eclipse SDK is designed as the basis for internationalized products. 
  The user interface elements provided by the Eclipse SDK components, including 
  dialogs and error messages, are externalized. The English strings are provided 
  as the default resource bundles.</p>
  
<p>Latin-1 locales are supported by the Eclipse SDK on all of the above 
  operating environments; DBCS locales are supported by the Eclipse SDK 
  on the Windows, GTK, and Motif window systems; BIDI locales are supported by 
  the Eclipse SDK only on Windows operating environments.</p>

<p>The Eclipse SDK supports GB 18030 (level 1), the Chinese code page 
  standard, on Windows XP and 2000, and Linux/GTK.</p>

<p>German and Japanese locales are tested.</p>

<h4>BIDI support</h4>

<p>SWT fully supports BIDI on Windows. On Linux GTK, SWT supports entering 
  and displaying BIDI text. Within these limitations, the Eclipse
  SDK tools are BIDI enabled.</p>
  
<h2><a name="Compatibility"></a>Compatibility with Previous Releases</h2>

<h3>Compatibility of Release 3.3 with 3.2</h3>

<p>Eclipse 3.3 will be compatible with Eclipse 3.2 (and, hence, with 3.1 and 3.0).</p>
<p>
  <strong>API Contract Compatibility:</strong> Eclipse SDK 3.3 will be upwards contract-compatible 
  with Eclipse SDK 3.2 except in those areas noted in the 
  <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.platform.doc.isv/porting/eclipse_3_3_porting_guide.html" target="_top">
    <em>Eclipse 3.3 Plug-in Migration Guide</em>
  </a>. 
  Programs that use affected APIs and extension points will need to be ported to
  Eclipse SDK 3.3 APIs. Downward contract compatibility is not supported.
  There is no guarantee that compliance with Eclipse SDK 3.3 
  APIs would ensure compliance with Eclipse SDK 3.2 APIs. Refer to 
  <a href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs">
    <em>Evolving Java-based APIs</em>
  </a> for a discussion of the kinds of API changes that maintain 
  contract compatibility.
</p>
<p><strong>Binary (plug-in) Compatibility:</strong> Eclipse SDK 3.3 will be upwards binary-compatible 
  with Eclipse SDK 3.2 except in those areas noted in the
  <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.platform.doc.isv/porting/eclipse_3_3_porting_guide.html" target="_top">
    <em>Eclipse 3.3 Plug-in Migration Guide</em>
  </a>. 
  Downward plug-in compatibility is not supported. Plug-ins for Eclipse SDK 3.3
  will not be usable in Eclipse SDK 3.2. Refer to
  <a href="http://wiki.eclipse.org/index.php/Evolving_Java-based_APIs">
    <em>Evolving Java-based APIs</em>
  </a> for a discussion of the kinds of API changes that maintain 
  binary compatibility. 
</p>
<p><strong>Source Compatibility:</strong> Eclipse SDK 3.3 will be upwards source-compatible 
  with Eclipse SDK 3.2 except in the areas noted in the 
  <a href="http://dev.eclipse.org/viewcvs/index.cgi/%7Echeckout%7E/org.eclipse.platform.doc.isv/porting/eclipse_3_3_porting_guide.html" target="_top">
    <em>Eclipse 3.3 Plug-in Migration Guide</em>
  </a>. 
  This means that source files written to 
  use Eclipse SDK 3.2 APIs might successfully compile and run against Eclipse 
  SDK 3.3 APIs, although this is not guaranteed. Downward source compatibility 
  is not supported. If source files use new Eclipse SDK APIs, they will not be 
  usable with an earlier version of the Eclipse SDK. 
</p>
<p><strong>Workspace Compatibility:</strong> Eclipse SDK 3.3 will be upwards workspace-compatible 
  with Eclipse SDK 3.2 unless noted. This means that workspaces and projects created 
  with Eclipse SDK 3.2, 3.1 or 3.0 can be successfully opened by Eclipse SDK 3.3 and 
  upgraded to a 3.3 workspace. This includes both hidden metadata, which is localized 
  to a particular workspace, as well as metadata files found within a workspace 
  project (e.g., the .project file), which may propagate between workspaces via 
  file copying or team repositories. Individual plug-ins developed for Eclipse 
  SDK 3.3 should provide similar upwards compatibility for their hidden and visible 
  workspace metadata created by earlier versions; 3.3 plug-in developers are responsible 
  for ensuring that their plug-ins recognize 3.2, 3.1, 3.0, 2.1, and 2.0 metadata and 
  process it appropriately. User interface session state may be discarded when 
  a workspace is upgraded. Downward workspace compatibility is not supported. 
  A workspace created (or opened) by a product based on Eclipse 3.3 will be unusable 
  with a product based an earlier version of Eclipse. Visible metadata files created 
  (or overwritten) by Eclipse 3.3 will generally be unusable with earlier versions 
  of Eclipse. 
</p>
<p><strong>Non-compliant usage of API's</strong>: All non-API methods and classes, and
  certainly everything in a package with "internal" in its name, are
  considered implementation details which may vary between operating environment
  and are subject to change without notice. Client plug-ins that directly depend
  on anything other than what is specified in the Eclipse SDK API are inherently
  unsupportable and receive no guarantees about compatibility within a single
  release much less with earlier releases. Refer to
  <a href="http://www.eclipse.org/articles/Article-API%20use/eclipse-api-usage-rules.html">
    <em>How to Use the Eclipse API</em>
  </a> for information about how to write compliant plug-ins.
</p>

<h2><a name="ThemesandPriorities">Themes and Priorities</h2>
<p>
  The PMC of the Eclipse Project has identified six major areas of work, 
  that will be the priorities for this development cycle. These areas will
  address the major themes identified by the Eclipse Requirements Council 
  (<a href="http://www.eclipse.org/org/councils/roadmap_v2_0/themes_v2_0.php">Themes and Priorities v2.0</a>).
</p>

<h2><a name="WorkAreas">Work Areas</h2>

<p>
  Although there are four projects under the top-level Eclipse Project, there
  is a significant amount of commonality and shared effort between them. 
  In general, many plan items involve coordinated changes to multiple
  components, and thus attempting to separate the items into
  sections based on sub-project leads to artificial distinctions between
  them (e.g. Platform Text vs. JDT Text, Platform Debug vs.
  JDT Debug, etc.).
</p>
<p>
  In order to provide the clearest focus for our development effort, we
  have organized the items below into sections based on the work area they
  are intended to address. Items that apply to multiple
  work areas are categorized based on where the most effort is expected
  to occur. In all cases, the items listed reflect new features of Eclipse
  or areas where existing features will be significantly reworked. Numbers in
  parentheses link to bugzilla problem reports where progress on that 
  item can be tracked and discussed.
</p>
<p>
  The major work areas are:
</p>
<ul>
  <li><a href="#Components">Components</a></li>
  <li><a href="#Consumability">Consumability</a></li>
  <li><a href="#Java">Java</a></li>
  <li><a href="#Vista">Vista</a>
  <li><a href="#UIEvolution">UI Evolution</a>
  <li><a href="#API">API</a>
</ul>

<!-- Start of Sections by Work Area -->

<h2><a name="Components">Components</a></h2>
<p>
  This work will enhance Eclipse's use of, and support for, software components,
  covering everything from component programming models such as Declarative
  Services, API tools, incremental building and fine-grained function delivery.
</p>

<h4>Committed Items (Components)</h4>
<blockquote> 

<p><strong>Target Provisioning.</strong>
    Currently, users wanting additional function supplied by others must
    manually acquire and install these additional bundles in their target
    platform.  This process is tiresome and error-prone.  As an extension
    to the proposed provisioning work, we will add the ability to provision
    targets directly from bundle repositories as well as from other locations
    on the local machine.
    [PDE]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154081">154081</a>) 
</p>

<p><strong>Application Model.</strong>
    The OSGi R4 MEG specification includes an application model that significantly
    decouples the application from the rest of the system.  The net result is OSGi
    (and thus Eclipse) as a more flexible application container, for example allowing
    multiple applications to run concurrently and improved lifecycle around the
    application.  These characteristics are important both to the manageability of
    the system (e.g., simplifying and clarifying the shutdown process) but also to
    various RCP scenarios such as Kiosk-mode and Application Container models.
    In 3.3 we will implement and adopt the MEG application model.
    [Equinox]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154084">154084</a>) 
</p>

<p><strong>OSGi R4.1 Specification Work.</strong>
    Much of the success Eclipse has enjoyed with OSGi comes from the fact that the
    Eclipse community has played a very active role in the evolution of various
    OSGi specifications.  With increased interest in OSGi and Java modularity
    (see JSR 277, JSR 291 and JSR 232) this participation has never been more important.
    In addition to promoting Eclipse use-cases and the evolution of these standards
    to benefit Eclipse, there are a number of gaps in the OSGi specifications that
    Eclipse is currently filling in specific ways and should be addressed in R4.1.
    For example the management of API in metadata (x-friends and x-internal),
    integration techniques for third party and legacy code, in-place execution of
    bundles, basic notions of data location, etc.  The Equinox team will continue
    their active participation in these specification processes and keep Eclipse
    on the leading edge of Java componentization.
    <em>(Note that originally this plan item referenced "OSGi R5" but the next version
    of the spec is going to be called "R4.1" so we have updated the item accordingly.)</em>
    [Equinox]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154085">154085</a>) 
</p>

<p><strong>Server side support.</strong>
    First it was tools, then it was applications, now server-side programmers are
    waking up to the power of componentization delivered by Eclipse and OSGi.
    In the 3.2 cycle an Equinox incubator was started to investigate the use of
    Eclipse on the server.  It started as a very modest servlet bridge allowing
    Eclipse to run inside a servlet engine and handle servlet requests and has been
    evolving into a full-blown appreciation of what it means to componentize server
    software.  There are many possible directions here and there is no way the
    Equinox team proper will be able to track, support and participate in all.
    However we will spend time understanding the basic requirements as they apply
    to the base framework and add-on services and look to support the use-cases
    presented by various other Eclipse projects that are adopting Eclipse on the
    server (e.g., ECF, ECP, Corona).
    [Equinox]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154087">154087</a>) 
</p>

<p><strong>Help content generated on-the-fly</strong>
    Currently it is not possible to write all your help content in your own
    format, and have it converted into HTML, TOC, keyword index, and context
    help on-the-fly. For the table of contents you must supply the information
    in the toc XML format, you cannot use any other format or write code to
    contribute tocs. The same restriction exists with keyword index content.
    This item consists of adding API for toc and keyword index providers,
    and ensuring that a full end-to-end generated doc set is possible.
    [UA]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175016">175016</a>) 
</p>

<p><strong>Improve componentization of user assistance content</strong>
    More flexibility for filtering, such as OR and IF/ELSE clauses in filter
    condition, and ability to plug-in any type of filter. Adopt help's extension
    features and content replace for all other forms of user assistance (e.g.
    welcome, cheat sheets). Also provide a better mechanism to
    control how UA content is arranged and ordered (for example, the order of
    books in the table of contents). 
    [UA]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175018">175018</a>) 
</p>

</blockquote>
<h4>Proposed Items (Components)</h4>
<blockquote>

  <p><i>None at this time.</i></p>

</blockquote>
<h4>Deferred Items (Components)</h4>
<blockquote> 

<p><strong>API tools.</strong>
    More components means more API and an elevated need for solid APIs,
    evolved but compatible APIs and the correct and understood use of APIs.
    This cannot be achieved without supporting tooling.  Today PDE includes
    sophisticated support for classpath management and access rule management
    based on information in the manifest of bundles to facilitate the capture
    of package and class references.  In 3.3. we will expand this to cover
    finer-grained API contracts (e.g., clients should not call foo() or
    extend Bar).  Similarly, developers will be given effective mechanisms
    for discovering, visualizing and minimizing dependencies in their code, 
    bundles produced by third parties and non-bundled code libraries.  Tooling in support
    of checking and managing the evolution of component and package version numbers
    will also be supplied.
    [PDE]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154078">154078</a>) 
</p>
  
<p><strong>Bundle/Module Development Tools.</strong>
    In 3.1 and 3.2 PDE made gigantic strides in support for
    traditional OSGi bundle development. Even still, in 3.3. we will improve
    various workflows and classpath management strategies to promote the
    development of robust and independent right-grained components. This
    covers everything from increased quick-fix and manifest editing support
    to deeper integration with JDT (e.g., support for searching JARs that
    are not in the workspace without implicitly importing the JARs). In
    addition, as JSR 291 evolves in the Java SE 6 time frame, PDE will be
    there to provide developer support. 3.3 will include tooling around OSGi
    Declarative Services and the new application model as well as improved
    support for launching other frameworks, Java applications with bundle
    based classpaths and "hot launching" frameworks.
    <em>(Note: significant work was done on this item, but not enough to cover
    it's full scope. See the bug for more info.)</em>
    [PDE]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154079">154079</a>) 
</p>
      
<p><strong>Incremental Plug-in Build.</strong>
    With the increase in plug-ins coming from and going to third parties the
    development cycle needs to be more incremental.  In the Eclipse project
    itself we have started to consume pre-built plugins such as ICU4J and SSH2.
    This trend is likely to continue as, for example, Apache seeks to deliver
    their libraries as bundles and more people look to consume individual
    bundles/components from Equinox and similar projects.  As such, the build
    process should support the incremental building of plug-ins (that is
    building plugins individually) based on a set of pre-built plugins kept
    in some sort of provisioning repository.  Plug-ins coming out of the build
    should feed into said repository to be used as a base for future builds.
    This ability will in turn enable the more frequent building of whole
    systems (since you build only what has changed) and simplify incremental,
    milestone and release build cycles.
    [PDE Build]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154083">154083</a>) 
</p>

<p><strong>Improved support for provisioning.</strong>
    Eclipse has advanced quite quickly with new use-cases (RCP, Equinox, 
    server side, etc.) and new technologies (e.g., OSGi and OSGi's MEG) coming
    into the picture.  To date Update Manager has not been enhanced to support
    or exploit these changes. In 3.3 we will investigate provisioning support
    for enhanced workflows, the ability to update the so-called "root files"
    (e.g., startup.jar, eclipse.exe), improved efficiency (download and disk
    footprint), support for right-grained discovery and acquisition of function
    as well as integration with differing repository types. This effort also
    includes enhancements to the tooling around provisioning.
    [Update]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154077">154077</a>) 
</p>

<p><strong>Bundle Management.</strong>
    Managing even modest systems of bundles can be complex and error prone.  There are 
    several places in PDE where developers need to list or select sets of bundles (e.g.,
    launch configurations, target setup, etc).  In many cases the environment already
    includes relevant grouping constructs (e.g., features, working sets, bundle groups).
    PDE should surface these to developers in a clear, consistent and pervasive 
    fashion.
    [PDE]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154082">154082</a>) 
</p>

</blockquote>

<p>(End of items for Components.)</p>

<h2><a name="Consumability">Consumability</a></h2>
<p>
  This work will make it easier for users to get Eclipse, install it on
  their systems, and configure it for their use. It will also enhance
  the error handling and reporting mechanisms to make it easier to service
  Eclipse in the field. Finally, it will improve the scalability and
  performance of Eclipse, to provide a better experience for users working
  with many plug-ins and large data sets.
</p>

<h4>Committed Items (Consumability)</h4>
<blockquote> 

<p><strong>Remote help</strong>
    Packaging a comprehensive set of help content with a product can significantly
    increase its size. Instead of bundling it with the product, allow help content
    to be served from a remote infocenter. This includes all forms of help content:
    documents, table of contents, keyword index, and context help. Local content is
    also allowed alongside the remote content, and it should behave and appear to
    the user as though it were installed locally. 
    [UA, Releng]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175006">175006</a>) 
</p>
  
<p><strong>Improve the launching experience.</strong>
    We will look for ways to improve the current launching experience. This
    may include efforts such as using SWT to build the splash screen,
    improving the look and utility of the workspace launcher, supporting
    "fast switching" between workspaces, and simplifying the experience for
    first-time users.
    [SWT, Runtime, Workspace, UI, UA]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154088">154088</a>)
</p>

<p><strong>Improve serviceability.</strong>
   When an end user encounters a problem with Eclipse, it is important for
   support teams to be able to diagnose the root cause of the failure, and
   identify the failing plug-in. Eclipse should have enhanced error reporting
   tools that make it easy for end users to report problems. Tools should be
   available at all times, so that knowledgeable users can diagnose
   unexpected behavior such as slow-downs or exceptional memory use. Error
   handling is done in a variety of ways within the platform which are not
   extensible to RCP applications. An improved story would allow for the
   inclusion of application defined error support (such as a link to a support centre 
   for the product) and remote monitoring/inspection of system health and would 
   tie the current error reporting story together into a solution with a more 
   consistent look and fewer error reporting paths for developers.
   [Runtime, UI]
   (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154090">154090</a>)
</p>

<p><strong>Managing and sharing settings.</strong>
    Currently settings are either scoped at the workbench/workspace level or the
    project level. However, there are cases where associating settings with
    other scopes, such as a working set or perspective, would be beneficial.
    Similarly, a product should be able to specify the default settings for a 
    particular perspective. We will also look for ways to simplify how we share 
    settings and other interesting state, such as breakpoints, bookmarks, 
    perspectives, key bindings, etc.
    [Runtime, Workspace, UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154097">154097</a>)
</p>

<p><strong>Platform level proxy settings.</strong>
    There are at least three proxy settings pages in Callisto. We will work with
    the Eclipse community to make sure that the core capabilities from these
    pages are made available at the Platform level, as a single settings
    page that can be consumed by all.
    [Runtime, Team, Update, UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154100">154100</a>)
</p>

<p><strong>GTK Printing.</strong>
    We will provide printing support on GTK. 
    [SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154101">154101</a>)
</p>

<p><strong>Search based navigation.</strong>
    Because traditional navigation-by-browsing does not scale to large data
    sets, we should generalize and extend the existing search-based
    rapid navigation mechanisms (e.g. "Quick Find Class").
    [UI, UA]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154104">154104</a>)
</p>

<p><strong>Performance focus.</strong>
    We must continue to improve overall performance and memory consumption,
    with a particular focus on working with large numbers of plug-ins and 
    large amounts of data.
    [All components]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154106">154106</a>)
</p>

</blockquote>
<h4>Proposed Items (Consumability)</h4>
<blockquote> 

  <p><i>None at this time.</i></p>

</blockquote>

<h4>Deferred Items (Consumability)</h4>
<blockquote> 

<p><strong>Customization.</strong>
    Eclipse lacks customization capabilities aimed at end users and product
    packagers. More generally, component development and use is fraught with
    producer/consumer problems. Component producers implement solutions that
    address a number of use-cases and scenarios but inevitably consumers come
    up with additional, sometimes quite divergent requirements. We will
    investigate mechanisms and facilities that allow component consumers to
    "override" or replace metadata specifications in the components they are
    consuming.  Such mechanisms would, for example, allow consumers to configure
    menus, tool bars, and perspectives of their Eclipse installation as well
    as refine plug-in dependency declarations.
    [Runtime, UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154099">154099</a>)
</p>

<p><strong>Help keyword index</strong>
    In 3.2, keyword index support was added to the Help system. However, as yet the
    Eclipse SDK does not have keyword index content. This item consists of
    contributing a comprehensive and complete keyword index for Eclipse as
    well as the necessary tooling to create it (e.g. ant task to extract meta
    keywords from html, etc). This also includes UI enhancements for the overall
    presentation of the keyword index and any necessary usability enhancements.
    [UA, Doc]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175008">175008</a>) 
</p>

<p><strong>Ship Finer-grained Components.</strong>
    The Eclipse project produces three major outputs, the Platform, JDT and PDE.
    These are exposed as zips on download sites and features on update sites.
    Those wanting to get just part of one of these components (e.g., Help,
    Update, JDT Core) must first discover which zip or feature contains the
    desired function, acquire that container and finally identify and extract
    the desired plug-ins.  To make this easier we will revise the grouping structure 
    to capture more independent and re-usable components. 
    [All components]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154102">154102</a>) 
</p>

</blockquote>

<p>(End of items for Consumability.)</p>

<h2><a name="Java">Java</a></h2>
<p>
  The Eclipse Java Development Tools are the premier Java development
  environment in the industry today. We must address the new capabilities
  of Java SE 6 and continue to refine and extend the features JDT provides to
  maintain its leadership position.
</p>

<h4>Committed Items (Java)</h4>
<blockquote> 

<p><strong>Enhance launching support.</strong>
    We should simplify the launch experience for novice users with single
    click, context sensitive launching, and with launch configurations
    managed via resource properties. For advanced scenarios, we should
    allow plug-ins to contribute additional pages to launch configurations so
    that plug-in specific information (such as profiling and code coverage settings)
    can be associated with each configuration. Additionally we should support
    mixed mode launching, and allow more than one plug-in to contribute launchers
    for the same configuration type and mode (allowing the user to select a
    preferred launcher). 
    [Debug]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154107">154107</a>)
</p>
  
<p><strong>Extend Clean Up.</strong>
    Add formatting, organize import and sort members to 'Clean up',
    offer clean up profiles, and invoke clean up on user defined events. 
    [JDT UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154109">154109</a>)
</p>

<p><strong>Compiler API (JSR 199).</strong>
    In order to conform to the forthcoming tool API for compilers (JSR 199),
    the Eclipse compiler should provide a front-end implementing the tool API
    included in Java SE 6. 
    [JDT Core]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154111">154111</a>)
</p>

<p><strong>Support for Java SE 6 debug features.</strong>
    Implement new Java SE 6 features in the Eclipse Java Debug Interface (JDI)
    client including support for heap walking (retrieve instance counts, all
    intances of specific types, and all references to an object), forcing an
    early return from a method with a specific return value, and improved class
    prepare event filtering.
    [JDT Debug]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154115">154115</a>)
</p>

<p><strong>Enhance Annotation Processing Tooling.</strong>
    APT should support the new standard Annotation Processing API (JSR 269)
    introduced in Java SE 6, as opposed to the provisional API from Sun
    introduced in Java SE 5 that is currently implemented. Also, the APT
    integration in IDE should be improved in various areas, including editor
    reconciling and code assist. The editor reconciling experience should work
    correctly even if the Java builder is not active. Currently, if a processor
    generates types, those types are ignored during reconcile. Instead, they
    should be modeled using working copies, and provide the same level of
    functionality as JDT when autobuild is turned off. Also, on the code-assist
    front, we should provide a simple API for processors to supply domain
    specific knowledge to completions inside annotation values.
    [JDT APT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154110">154110</a>)
</p>

<p>(<img src="new.gif" alt="(new)" border="0" height="12" width="12"> committed)
   <strong>More refactorings.</strong>
    We will finish the 'Fix Deprecation' refactoring that didn't make it
    into 3.2, and add the new refactoring 'Replace Invocation'. More
    refactoring API will be offered in the plug-in org.eclipse.jdt.core.manipulation
    so the refactoring infrastructure can be used with a UI. 
    [JDT UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154108">154108</a>)
</p>

</blockquote>
<h4>Proposed Items (Java)</h4>
<blockquote> 

  <p><i>None at this time.</i></p>

</blockquote>

<h4>Deferred Items (Java)</h4>
<blockquote> 

<p><strong>Add more class file targets for compiler.</strong>
    The compiler should support more configurable class file targets, including
    CLDC 1.0, CLDC 1.1 and possibly JSR 14 (generics experimentation for 1.4
    VMs). 
    [JDT Core]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154113">154113</a>)
</p>
 
</blockquote>

<p>(End of items for Java.)</p>

<h2><a name="Vista">Vista</a></h2>
<p>
  Microsoft Vista is a significant new desktop platform that we expect
  will become available during this development cycle. We should fully
  support running the current, win32-based version of Eclipse on
  Vista. We should also port SWT to WinFX and the Windows Presentation
  Framework.
</p>

<h4>Committed Items (Vista)</h4>
<blockquote> 

<p><strong>Fully support the win32 version of SWT on Vista.</strong>
    We should ensure that applications built on the win32 version of
    SWT work as well as any other win32 API based application on 
    Vista. This will increase our testing and support effort and potentially
    require new development to work around platform specific differences. [SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154116">154116</a>)
</p>

<p><strong>Port SWT to WinFX and WPF.</strong>
    We should port SWT to WinFX and the Windows Presentation Framework. Since
    64-bit systems are becoming increasingly prevalent on the desktop, we should
    ensure that this port is both 64-bit and 32-bit capable.
    <em>(Note: In the 3.3 timeframe, we are committed to producing a WPF port
    that will be suitable for early access style investigation on the platform.
    Significant follow on performance and feature completeness work (such as 64-bit
    support) will occur in our next release.)</em>
    [SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154117">154117</a>)
</p>

</blockquote>
<h4>Proposed Items (Vista)</h4>
<blockquote> 

  <p><i>None at this time.</i></p>

</blockquote>
<h4>Deferred Items (Vista)</h4>
<blockquote> 

<p><strong>Generalize the win32 version of SWT to win64.</strong>
    We should merge the work being done by the Eclipse community to implement
    a win64 implementation of SWT into the main win32 code base. This will
    require extensive review of the new code and a significant effort to merge
    and test the pervasive changes.
    [SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154118">154118</a>)
</p>
  
</blockquote>

<p>(End of items for Vista.)</p>

<h2><a name="UIEvolution">UI Evolution</a></h2>
<p>
  The goal of this work is to provide a better basis for building modern,
  rich user-interfaces, by addressing areas where more flexibility and
  more consistency are needed. We will use these capabilities to refine 
  the user-interface of the Eclipse IDE. In addition, we will implement
  of the most requested missing IDE productivity features.
</p>

<h4>Committed Items (UI Evolution)</h4>
<blockquote> 

<p><strong>Investigate background saving of editors.</strong>
    Modern applications allow editing sessions to be saved in the background,
    allowing the user to continue editing or close the editor without waiting.
    We should investigate whether this style of interaction can be built
    on top of the Eclipse editor framework. [Platform Text, JDT Text, Platform UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154122">154122</a>)
</p>
  
<p><strong>Improve workbench usability.</strong>
    We should review how users interact with the workbench, such as
    how editors, views, and other screen real-estate are managed
    (e.g. fix the broken minimize), and find ways to make this a better
    experience for them. This includes improving the new trim
    support by allowing the end user to hide/show, close and otherwise
    configure trim items, improving navigation from hovers (e.g. quick diff),
    making fast views more flexible (fast views on all sides, fast view
    orientation affinity, fast view bars show text option).
    [Platform UI, Platform Text, JDT UI, JDT Text]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154120">154120</a>)
</p>

<p><strong>Mozilla Everywhere.</strong>
    For situations where the existing, platform-browser-based Browser
    control is not sufficient, we should support embedding of Mozilla on all
    platforms. This would allow developers to implement code that worked
    against a common back end, so that they could access a common DOM, or
    surface the browser's HTML editing support. 
    [SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154124">154124</a>)
</p>

<p><strong>UI Forms face-lift</strong>
    UI Forms will be refreshed visually and functionally. Color management will be
    revised to increase consistency of color across all the platforms Eclipse runs
    on. Enhancements will be made to both the header area and field decoration support.
    Eclipse SDK clients of UI Forms will take advantage of the new capabilities.
    [UA, PDE]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175158">175158</a>)
</p>

<p><strong>JFace Enhancements.</strong>
    Ensure that the reusable components in JFace fully support the SWT
    widget set, such as support for the new custom draw capabilities
    of the Table and Tree widgets. Also, implement some of the components
    that we do not use in the SDK currently that the community is 
    requesting.
    [Platform UI, SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154123">154123</a>)
</p>

<p><strong>Implement missing text editor productivity features.</strong>
    We should provide some of the long awaited productivity features that
    the community has voted for. Examples include double-click-drag to
    select multiple words, triple-click, extensible hyperlink support
    and spell checking. [Platform Text, Platform UI, SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154119">154119</a>)
</p>
  
<p><strong>Ubiquitous cheat sheets</strong>
    Cheat sheets will be commoditized by lowering the price of authoring and
    publishing. We will make it easy to whip up a cheat sheet quickly, hook
    appropriate commands for 'Do it for me' links, exchange cheat sheets as
    attachments or as URLs to remote cheat sheets.
    [UA, PDE, Doc]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175024">175024</a>) 
</p>

</blockquote>
<h4>Proposed Items (UI Evolution)</h4>
<blockquote> 

  <p><i>None at this time.</i></p>

</blockquote>

<h4>Deferred Items (UI Evolution)</h4>
<blockquote> 

<p><strong>Improve multi-instance view management.</strong>
    Views such as Search and Synchronize use a drop-down menu to manage 
    multiple pages. Another possibility would be to use multiple view instances. 
    However, the presentation and management of these two approaches are different.
    Multiple view instances should support different view presentations. That is, 
    the user (or product) should be able to decide whether multiple views use tabs 
    or a drop-down menu. There are also shortcomings in multi-view management 
    (e.g., views are managed at the perspective level but some tooling may require 
    the ability to close a particular view in all perspectives).
    [UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154121">154121</a>)
</p>
  
<p><strong>Help webapp refresh</strong>
    The Help web application's appearance does not currently match the workbench
    appearance well. However it is common for users to move back and forth between
    these two windows, resulting in an inconsistent experience for the user.
    We will refresh several aspects of the Help user experience, including
    presentation, accessibility issues, optional footer for legal information,
    automatic bread crumbs. <em>(Note: significant work was done on this item,
    but not enough to cover it's full scope. See the bug for more info.)</em>
    [UA]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=175023">175023</a>) 
</p>

</blockquote>

<p>(End of items for UI Evolution.)</p>

<h2><a name="API">API</a></h2>
<p>
  This work area deals specifically with issues concerning the application
  programming interfaces provided by the Eclipse Project. We will identify
  API whose function has been superceded, and ensure that the SDK does
  not depend on this API. We will encourage adoption within the SDK of
  some of the more recent additions to Eclipse, such as
  the command framework, Equinox preferences, tabbed
  properties and the common navigator. We will work with the community to
  ensure that needed functionality is made available as API, when it reaches
  appropriate levels of maturity.
</p>

<h4>Committed Items (API)</h4>
<blockquote> 

<p><strong>Generalize editor annotation and ruler support.</strong>
    We should allow plug-ins to contribute additional vertical rulers
    to show additional information (e.g. code coverage). We should
    support live annotate "color by age" in addition to "color by
    contributor".
    [Platform Text]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154125">154125</a>)
</p>
  
<p><strong>Adopt the new UI features.</strong>
    We should adopt the following items across the entire SDK UI: the new
    command framework, preference initializers, field assist, SWT column
    sort indicators, working sets, tabbed properties view and the common navigator.
    <em>(Note: This is an ongoing effort that will continue in the next release of Eclipse.)</em>
    [UI, JDT UI, PDE, Team, Text]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154127">154127</a>)
</p>
  
<p><strong>Provide access to more native controls.</strong>
    We should provide access to more of the native controls that are available
    on each platform, such as date and time pickers. 
    In addition, we should enable more features of existing native controls.
    [SWT, UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154128">154128</a>)
</p>

<p><strong>Custom widget API support.</strong>
    Investigate ways to simplify the process of writing custom widgets,
    including making available, as API, some of the currently internal
    capabilities of the custom widgets implemented in the SDK, such as
    drag under feedback for drag & drop.
    [SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154129">154129</a>)
</p>

<p><strong>Finish re-work of commands and key bindings.</strong>
    In 3.2, we built some important infrastructure that will allows us to
    rationalize our commands and key bindings story. We need to complete this
    effort, making sure the new story supports all of the existing
    functionality (e.g action sets), and migrate over to the new support.
    We also need to make it easier to add and edit key bindings.
    [UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154130">154130</a>)
</p>

<p><strong>JFace data binding.</strong>
    In 3.2, we developed a data binding framework for JFace but did not
    make it generally available. We should continue to work towards providing a 
    public API for this framework and investigate how it will be delivered and
    used within the SDK. 
    [UI]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154132">154132</a>)
</p>

<p><strong>Improve compare.</strong>
    The Compare plugin has not undergone much work in the last few releases
    and is showing it. From an architectural standpoint, there are several
    Compare internals that need to be made API in order to properly support
    clients and there are also several polish items that have been identified
    by Eclipse development teams. In addition, new ISaveable support was added
    in 3.2 and we should investigate integrating this into Compare. From a
    usability standpoint, the compare editor uses a custom viewer for content
    which appears similar to the related editor but has a reduced capability
    which is often confusing for users. Smaller usability issues involve
    breaking out the outline from the editor into the Outline view. There is
    supported by compare but is not used by Team or other Platform clients.
    [Team]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154133">154133</a>)
</p>

<p><strong>Graphics Improvements.</strong>
    The SWT graphics layer should provide support for fractional line widths,
    dashes and fonts, the ability to flatten paths, image loading/saving
    improvements, and other similar enhancements. 
    [SWT]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154134">154134</a>)
</p>

<p><strong>APIs for custom debugger integration.</strong>
    Publish public APIs based on the provisional APIs introduced in 3.2 to
    support custom debugger integration. Features include a debug context
    service supporting retargettable actions and debug command handlers
    (for operations such as step and terminate), custom detail panes in the
    variables view, flexible view wiring and pluggable source lookup. 
    [Platform Debug]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154135">154135</a>)
</p>

<p><strong>Adopt the Eclipse File System.</strong>
    We should ensure that use of the Eclipse File System is pervasive
    in the platform, and remove any barriers that prevent it from being
    more widely adopted by the community. For example, we should provide
    IFileStoreEditorInput and a matching default implementation.
    [Workspace, UI, Platform Text]
    (<a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=154126">154126</a>)
</p>

</blockquote>
<h4>Proposed Items (API)</h4>
<blockquote> 

  <p><i>None at this time.</i></p>

</blockquote>
<h4>Deferred Items (API)</h4>
<blockquote> 

  <p><i>None at this time.</i></p>
  
</blockquote>
<p>(End of items for API.)</p>

<!-- End of Sections by Work Area -->

<h2><a name="Appendix1">Appendix 1: Execution Environment by Plug-in</a></h2>

<p>In the table below, the "3.3 EE" ("3.3 Execution Environment") column
indicates the minimum Java class library requirements of each plug-in
for the 3.3 release, where the value is one of:</p>
<table border="0" width="90%">
  <tbody>
    <tr>
      <td align="center"><b>Entry</b></td>
      <td align="left"><b>Meaning</b></td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>M1.0</strong></div>
      </td>
      <td>OSGi Minimum Execution Environment 1.0 - This is a subset of
      the J2ME Foundation class libraries defined by OSGi to be the base
      for framework implementations. See the OSGi specification for more
      details.</td>
    </tr>
    <tr>
      <td width="9%">
      <div align="center"><strong>M1.1</strong></div>
      </td>
      <td width="91%">OSGi Minimum Execution Environment 1.1 - This is a
      subset of the J2ME Foundation class libraries defined by OSGi to
      be the base for framework implementations. See the OSGi
      specification for more details.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>F1.0</strong></div>
      </td>
      <td>J2ME Foundation 1.0 - indicates that the plug-in can only be
      run on Foundation 1.0 or greater. Note that with the exception of
      some MicroEdition IO classes, Foundation 1.0 is a subset of J2SE
      1.3.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>F1.1</strong></div>
      </td>
      <td>J2ME Foundation 1.1 - indicates that the plug-in can only be
      run on Foundation 1.1 or greater. Note that with the exception of
      some MicroEdition IO classes, Foundation 1.1 is a subset of J2SE
      1.4.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>1.2</strong></div>
      </td>
      <td>J2SE 1.2 - indicates that the plug-in can only be run on JSE
      1.2 or greater.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>1.3</strong></div>
      </td>
      <td>J2SE 1.3 - indicates that the plug-in can only be run on JSE
      1.3 or greater.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>1.4</strong></div>
      </td>
      <td>J2SE 1.4 - indicates that the plug-in can only be run on JSE
      1.4 or greater.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>1.4/1.5</strong></div>
      </td>
      <td>Indicates that the plug-in can run on JSE
      1.4 or greater, but provides enhanced functionality when run on J2SE 5.0.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>1.5</strong></div>
      </td>
      <td>J2SE 5.0 - indicates that the plug-in can only be run on JSE
      5.0 or greater.</td>
    </tr>
    <tr>
      <td>
      <div align="center"><strong>1.6</strong></div>
      </td>
      <td>J2SE 6.0 - indicates that the plug-in can only be run on JSE
      6.0 or greater.</td>
    </tr>
    <tr>
      <td align="center"><b>n/a</b></td>
      <td>Unknown at the time of this revision.</td>
    </tr>
  </tbody>
</table>
<br>
<b>Table of minimum execution environments by plug-in.</b>
<br>
<br>
<table border="1">
  <tbody>
    <tr>
      <td width="290"><strong>Plug-in</strong></td>
      <td width="60">
      <div align="center"><strong>3.3 EE</strong></div>
      </td>
    </tr>
    <tr>
      <td>javax.servlet</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>javax.servlet.jsp</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.apache.ant</td>
      <td>
      <div align="center">1.2</div>
      </td>
    </tr>
    <tr>
      <td>org.apache.commons.el</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.apache.commons.logging</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.apache.jasper</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.apache.lucene</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ant.core</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ant.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.compare</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.boot</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.commands</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.contenttype</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.expressions</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.filebuffers</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.filesystem</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.jobs</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.net</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.resources</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.resources.compatibility</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.runtime</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.runtime.compatibility</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.runtime.compatibility.auth</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.runtime.compatibility.registry</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.core.variables</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.debug.core</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.debug.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.app</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.common</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.http.jetty</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.http.servlet</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.http.registry</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.jsp.jasper</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.jsp.jasper.registry</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.launcher</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.preferences</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.equinox.registry</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.help</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.help.appserver</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.help.base</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.help.ui</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.help.webapp</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.apt.core</td>
      <td>
      <div align="center">1.5</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.apt.ui</td>
      <td>
      <div align="center">1.5</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.compiler.apt</td>
      <td>
      <div align="center">1.6</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.compiler.tool</td>
      <td>
      <div align="center">1.6</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.core</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.core.manipulation</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.debug</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.debug.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.doc.isv</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.doc.user</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.junit</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.junit.runtime</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.junit4.runtime</td>
      <td>
      <div align="center">1.5</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.launching</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.source</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jdt.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jface</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jface.text</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jsch.core</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.jsch.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ltk.core.refactoring</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ltk.ui.refactoring</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.osgi (system.bundle)</td>
      <td>
      <div align="center">M1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.osgi.services</td>
      <td>
      <div align="center">M1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.osgi.util</td>
      <td>
      <div align="center">M1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.build</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.core</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.doc.user</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.junit.runtime</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.runtime</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.source</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.pde.ui.templates</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.platform</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.platform.doc.isv</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.platform.doc.user</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.platform.source</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.platform.source.*</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.rcp</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.rcp.source</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.rcp.source.*</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.sdk</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.search</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.swt</td>
      <td bgcolor="#ffffff">
      <div align="center">M1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.swt.*</td>
      <td bgcolor="#ffffff">
      <div align="center">M1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.team.core</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.team.cvs.core</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.team.cvs.ssh</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.team.cvs.ssh2</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.team.cvs.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.team.ui</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.text</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.tomcat</td>
      <td>
      <div align="center">n/a</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.browser</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.cheatsheets</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.console</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.editors</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.externaltools</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.forms</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.ide</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.intro</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.navigator</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.navigator.resources</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.net</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.presentations.r21</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.views</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.win32</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.workbench</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.workbench.compatibility</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.ui.workbench.texteditor</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.update.configurator</td>
      <td bgcolor="#ffffff">
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.update.core</td>
      <td bgcolor="#ffffff">
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.update.core.linux</td>
      <td bgcolor="#ffffff">
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.update.core.win32</td>
      <td bgcolor="#ffffff">
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.update.scheduler</td>
      <td bgcolor="#ffffff">
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.eclipse.update.ui</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
    <tr>
      <td>org.junit (old)</td>
      <td>
      <div align="center">1.4</div>
      </td>
    </tr>
    <tr>
      <td>org.junit (JUnit4)</td>
      <td>
      <div align="center">1.5</div>
      </td>
    </tr>
    <tr>
      <td>org.mortbay.jetty</td>
      <td>
      <div align="center">F1.0</div>
      </td>
    </tr>
  </tbody>
</table>
</body>
</html>